Throughout this specification the use of the word “inventor” in singular form may be taken as reference to one (singular) inventor or more than one (plural) inventor of the present invention.
The inventors have identified a number of limitations with using third party “cloud” service or storage providers for sharing information, especially if user information is confidential, sensitive or private. These limitations include security, privacy and control. In particular, the reliance on a trusted third party(s) (TTP) and/or passwords.
“Cloud” providers include Software-as-a-Service (SaaS) providers, Platform-as-a-Service (PaaS) providers, Infrastructure-as-a-Service (IaaS) providers and any other providers that offer information sharing services such as customer management services, storage services, messaging services, file sharing services, electronic data vaults, virtual data rooms, collaboration tools, screen sharing tools, content management systems, social websites, social networks, instant messaging, group-chat, forums, network management, content syndication, gaming, remote systems control and monitoring, geo-location, Voice over IP (VoIP), telephony, video conferencing, identity services and/or any other information sharing middleware or “cloud” based applications.
Problems with trusted third parties mostly arise because of the way they centralise their services in order to achieve business goals such as efficiency, supportability, account control, market adoption etc. These problems, which may include inadequate security, nominal privacy and/or lack of control by the end-users, are evidenced by the ongoing and increasing number of hacks, data breaches, audit failures and criticisms in formal security reviews. The broad reasons why third-party providers find it difficult to “lock-down” server-side infrastructure and operations include:                Controls—Server-side security relies on “controls” to prevent mishaps, breaches and/or abuse in the delivery of services. However, controls are considered rarely adequate because of the complexities of too many people (staff, administrators, contractors, help desk personal etc.) having too many privileges (running, maintaining, administering, supporting etc.) across too many systems (including technologies, platforms, versions, topologies, business units, organisations etc.) with enforcement mostly by voluntary procedures (e.g. operations, development, testing, incident handling, patching, configuration, recovery, auditing). Controls are considered to cost money and effort, often with little perceived business benefit, and so are rarely broad, strong or given priority. Even if they are in place, they cannot guarantee against mistakes, malicious behaviour or being deliberately bypassed (or disabled) if they get in the way of “business imperatives”.        Change—Compounding these challenges is ongoing changes within any organisation. There are changes in technology (new systems, new platforms, new functionality and endless upgrades and patches etc.), changes in business operations (as a result of new markets, new partners, new opportunities/threats and acquisitions/divestments), and changes in staff (including their roles, responsibilities and priorities whenever there are re-organisations, new hires, resignations or promotions etc.). All this is considered bad for security. Even worse, security budgets may be limited, and so security analysis, measurement and remediation may be patchy, inadequate, take long periods to implement or be seen as too expensive to pursue.        Verification—Even if controls are in place, the server-side nature of the service is considered to make it nearly impossible for end-users to validate the effectiveness of the controls or even to know if any breach has occurred. In effect, these controls are “voluntary” and end-users have no choice but to completely “trust” the security and privacy of their information to their service provider. Even if a user suspects a breach or other unauthorised activity, the service provider may not willingly, or have the capacity, to provide logs or forensic data about the activities in question.        Internal Threats—Even if controls are adequate and could be properly verified, this may not remove the risk of internal threats, as administrators may always have the means to view user information and/or override any controls that users put on their information. For example, administrators may have the means to access user data and/or be able to manipulate security data such as alter information about users, impersonate users, set controls, change rights, alter groups, change memberships, view log files, access keys, reset passwords, utilised network inspection devices etc. They may even have means to avoid controls/detection and/or cover-up inappropriate activity.        Provider Misuse—Even if administrators can be controlled, user data may still be abused at the business level, such as when information is used by the service provider for its own commercial purposes. For example, the service provider, or associated partners, may sell, track, archive, backup, aggregate, resell, correlate, target and/or otherwise take advantage of end-user information. The lack of privacy (that end-users have with their own data) is evidenced by service provider Terms of Service which may claim a right to use or access user data for any purpose that the service provider deems necessary to run their service.        Outsourcing—The above problems of controls, change, verification, internal threats and provider misuse may be further aggravated by outsourcing, as problems may compound with each outsourced organisation involved in the delivery of a service.        
Even if the above TTP/centralisation risks could be minimised, most service providers rely on passwords for authenticating user access. Problems with passwords include poor security (e.g. password guessing, password stealing etc), ongoing maintenance (e.g. registration, provisioning, de-provisioning, password reminders, password reset etc.) and poor practices by end users (passwords are often forgotten, of poor quality, re-used etc.). Passwords may be considered weak and subject to attacks including guessing, “brute force” attacks and/or “phishing” attacks. In particular, it is considered very poor practice to share passwords as they cannot effectively be controlled or changed in the case that there is a change in the set of users needing to know the password. Thus, sharing of passwords should be avoided in any system that facilitates sharing of information.
Further, there are many problems associated with recovering from lost or forgotten passwords. These problems may include administrative overheads, security risks and/or loss of user's data. In password based systems, recovery relies on supplying or resetting the server-side password using either an automatic procedure, such as following a password reset via an email link, or a manual procedure, such as an administrator issuing a new password. Automatic password reset procedures, especially those that rely on just an email address, are considered to have poor security as they perform minimal validation, for example they are relatively susceptible to an attacker using a compromised account. Manual password reset procedures are considered to have poor security as they are relatively susceptible to weaknesses with administrators, such as using social engineering techniques to trick administrators, accidental mistakes by administrators or malicious activity by rogue administrators.
As a result of the above risks, third-party service providers, especially “cloud” storage providers, are rarely considered to be able to meet the requirements of strong security and privacy. This is further evidenced by their standard service agreements which generally absolve the service provider from any liability, obligation or responsibility for anything that might go wrong e.g. misuse, leaks, loss, damage, disclosure, data breaches etc. Similarly their privacy policies may come down to “best efforts” and/or may be non-binding.
FIG. 1a illustrates a typical prior art system. Users authenticate themselves to a Provider using a password and sharing of Data relies on the Provider enforcing access controls appropriately on the Data. Such systems are not considered to have strong security or privacy as they use passwords (with consequential risks as described above) and/or rely on the Provider as a TTP (with consequential risks as described above) and/or use password reset for recovering credentials (with consequential risks as described above).
Overall, most prior art approaches to security management tend to try to protect every aspect of the infrastructure where data may reside e.g. networks, servers, routers, hosts etc. This may be increasingly difficult as the world becomes more interconnected, as new technologies emerge, as complexity of systems increase, as attackers get more sophisticated, etc. Further, security tends to be centrally managed, because of the necessity to manage every aspect of security e.g. patch management, configuration management, entitlements management, role management, privilege management, authentication management etc. Centralisation may lead to other problems, such as the reliance on trusted administrators and/or trusted third parties which becomes even more difficult as the number of involved organisations increases.
An alternative approach is to protect the data using encryption. Encryption effectively “locks up” data in a tamperproof package protecting it where ever it is. The security of encrypted data thus needs to have less reliance on the security of the infrastructure it transits and/or is stored. In practice, user-to-user encryption also requires the management of keys, trust and other aspects. However, the current prior art is considered to be piece meal in that only particular aspects of the encryption problem have been solved, and not an integrated approach.
FIG. 1 b illustrates a typical prior art system commonly used for personal or backup reasons. In the client application, Password Based Encryption (PBE) makes use of a password to encrypt user data locally e.g. by directly using the password or using a key derived from the password. The encrypted Data is then stored by the Provider and the encryption safeguards the Data from abuse or failures by the Provider. However, when such systems are used for sharing, they are not considered to have strong security or privacy as they require the sharing of passwords (with consequential risks as described above).
FIG. 1 c illustrates a typical prior art system that allows users to encrypt and decrypt information with the assistance of a Key Server. Centralisation of keys is often used to overcome difficulties with key management including key generation, storage, duplication, distribution, access, protection, rollover, rotation, recovery, removal, and revocation. However, this centralisation requires that a TTP maintains the Key Server (with consequential risks of having effective controls as described above). In particular, Key Servers inherently have very concentrated control (possession of many keys) which may make them a target for attack. Further, the TTP controlling the Key Server may not necessarily be trusted in wider environments, for example, with diverse and/or large numbers of users and/or multiple collaborating organisations, especially over the wider internet. Also, many Key Servers only require password related authentication (with consequential risks as described above).
FIG. 1d shows an example of prior art systems that make use of public key cryptography (PKC) to enable users to share data encryption keys. Web of Trust (WoT) system may make use of endorsers to support trust in public keys. Public Key Infrastructure may make use of one or more trusted organisations to have reliable and secure processes to support trust in certificates containing public keys. However, such systems rely on a trusted third party(s) to facilitate the issuance and/or endorsement and/or distribution of public keys and/or certificates. This may give rise to a number of problems, for example:                PKI and WoT systems may have limitations in their trust models. In the case of PKI a Certification Authority (CA) issues certificates containing public keys and users have no choice but must trust the practices and procedures of the organisation running the CA, in particular the proof-of-identity that was used to issue a user their (public key) certificate. In the case of WoT, users must trust other users who endorse/notarise/counter-sign self-signed public keys.        PKI and WoT systems may have issues with security. Security issues with PKI relate to its dependence on a centralised TTP (risks described above). Security problems with WoT relate to the unreliable nature of “crowd sourced” trust as well as the difficulty of revoking public keys that have been compromised. Additionally, though WoT model allows anyone to issue certificates, the discovery and distribution generally relies on centralized keyservers or certificate repositories or public directories to store certificates and respond to queries and which introduces the problem that these keyservers/repositories/directories need to be run by a TTP (with consequential risks as described above).        PKI and WoT systems may have issues with privacy. Privacy issues in PKI relate to personal data divulged to the PKI Service during certificate issuance and/or as a result of certificates being publically available, such as in a directory and/or public website. Privacy issues relating to WoT relate to the visibility of counter signed signatures, especially if made visible in a directory and/or public website, which can reveal entire social networks about the owner.        PKI and WoT systems may have issues with cost, complexity and/or adoption. In the case of PKIs, adoption may be limited because of regional and/or organisational restrictions that CA's have to verify identity. In the case of WoT, adoption may be restricted because of limitations in the technology and/or the very technical and manual nature of communities having to build up their trust relationships.        Systems built using PKI or WoT may heavily rely on the continuity of credentials. For example, if credentials are lost and/or revoked, then keys being protected by those credentials may be lost, which may result in the loss or compromise of encrypted data.        
In summary, prior art encryption approaches may have many limitations. For example, the management of trust, credentials, certificates, keys etc. Password Based Encryption (PBE) approaches are considered to have numerous problems relating to managing passwords. Keyserver approaches are considered to have numerous problems relating to the difficulty of securing and managing all the keys in a single or relatively small number of places. Public/private key approaches are considered to have numerous problems relating to trusting a central server to reliably obtain a trusted public key(s) or certificate(s).
Thus, overall, in the field of security management, there is an ongoing need to protect electronic data, particularly data being transferred and/or shared between users. Such users, who may be anywhere over the wider internet, would like to get improved security and privacy from service providers, especially when transferring and/or sharing information that may be sensitive or confidential. In particular, end-users would like to use “cloud” services and other communications solutions, but in a way that is protected from and/or relatively independent from those third party providers themselves.
It is to be appreciated that any discussion of documents, devices, acts or knowledge in this specification is included to explain the context of the present invention. Further, the discussion throughout this specification comes about due to the realisation of the inventor and/or the identification of certain related art problems by the inventor. Moreover, any discussion of material such as documents, devices, acts or knowledge in this specification is included to explain the context of the invention in terms of the inventor's knowledge and experience and, accordingly, any such discussion should not be taken as an admission that any of the material forms part of the prior art base or the common general knowledge in the relevant art in Australia, or elsewhere, on or before the priority date of the disclosure and claims herein.